feat(runtime): start interactive sessions fresh instead of continuing - #56

A bare woopcode continued the newest session in the project, and App renders the home screen only when the timeline is empty (tui/src/app.tsx:42). Those two facts compose into a bug nobody wrote: from the second launch onwards the home screen silently stopped appearing, because the resumed conversation was hydrated into the timeline before the first frame. Nothing on screen said a conversation had been restored, or which one — the wordmark, the prompt examples and the capability row just stopped showing up, and the only way to get them back was a flag you had no reason to know about.

Resuming is now something you ask for. sessionOptionsFrom drops || mode === "interactive" from continueLatest, so a bare launch starts fresh in both modes and -c/--continue, --resume <ref> and a bare --resume picker are the ways back. -p already behaved this way, so the two entry points no longer disagree about a default — which is what made the old code need a paragraph of comment to explain itself.

The alternative was to keep continuing and render the home screen over the restored session. That is worse: it puts the wordmark and the prompt examples of a fresh start in front of a conversation the model can already see, which is the same invisible state with a friendlier face on it. --new is kept rather than removed — it is the interactive default now, but it still does real work beside -p --continue, and dropping a shipped flag breaks callers.

Nothing is lost by this. The session file is still written after every turn, and a launch that takes no turn writes nothing at all, so fresh-by-default leaves no empty sessions behind.

One consequence worth flagging for review: a bare --resume used to open its picker over the newest session, so Esc fell back into it. Nothing is loaded behind the picker now, so Esc leaves you in the fresh session instead. SessionPicker already optional-chains controller.currentSession?.()?.id, so it handles having no active session, and the stale comment at the call site is corrected in this commit.

Five doc files carried the old promise: docs/guides/sessions-and-history.md (intro, the resuming table, and the "Two windows on one conversation" section, whose premise was that both windows auto-continue), docs/reference/cli.md, docs/getting-started/first-session.md, docs/introduction/how-a-turn-works.md and README.md. The last two were already wrong before this change — both still claimed history was one global file rather than per-project, which sessions replaced in #52 — so they are corrected here too rather than left half-true.

Verified with bun run verify --all, which printed 4 gate(s) passed (docs lint, docs surface, type check, tests); the pre-commit hook ran it again over the staged tree and printed 3 gate(s) passed, the docs surface being unaffected. The two rewritten tests in packages/tests/config/sessionFlags.test.ts were proven rather than trusted: restoring || mode === "interactive" made a bare interactive launch starts a fresh session fail with Expected: false / Received: true, and removing it again went green. The other nine tests in that file are untouched and still pass. A grep sweep for the old promise across docs/ and README.md returns only an unrelated hit about Anthropic thinking blocks.

Not verified: the actual TTY behaviour. bun test does not drive a real terminal, so the sequence that matters end to end — launch, send a message, quit, relaunch and see the home screen, then -c to get the conversation back, then --resume for the picker — has not been run and is worth doing by hand before this leaves draft.